Why do you need encryption? In two words: privacy and confidentiality.
As private persons, we nowadays store lots of information on our computers that is not necessarily secret, but just simply private. Many of us also at times have the need to use employer-owned computers and servers, as well as public servers, to store such information. It might be copies of electronic invoices, private letters, your CV etc.
In all these situations you might feel a little more comfortable knowing that regardless of physical access to the files by network administrators, service personnel or even other family members in your home network, your private information is still kept private.
As employees we frequently are responsible for information that is sensitive in various ways. It might be salaries if you're a manager, or customer data if you're in sales or support etc. This information is kept in confidence by you, and you have a responsibility to care for it as best you can.
In many cases it's not really enough to just store it on the corporate network server and apply appropriate restrictive access permissions. The information and files are still always available to support staff, network administrators etc. Even if you trust your colleagues, as you should, mistakes do happen and sometimes it's simply human to be curious. Anyone finding a file with his or her name on it will be sorely tempted to sneak a peek...
Finally, there are an increasing number of cases where legislation and similar rules come into play such as the FDA 21 Code of Federal Regulations Part 11; Electronic Records; Electronic Signatures and the Health Insurance Portability and Accountability Act, HIPAA, where encryption of confidential data is required under certain circumstances.
In these and similar situations encryption programs such as AxCrypt provide a secure and convenient method to provide privacy and confidentiality as appropriate.
Because it endeavors to only use accepted practices and algorithms, and is Open Source. Anyone may inspect the source code, check it for errors, omissions or back doors.
It is designed to run on Windows 95/98/ME/NT/2K/XP. Currently there is no Linux or Mac support.
When you enter a passphrase, either when encrypting or decrypting, there is a checkbox at the bottom of the dialog labeled with the text 'Remember this for decryption'.
AxCrypt maintains an in-memory cache of used passphrases - one to be used by default for encryption, and as many as you like to be tried for decryption before prompting you with a dialog.
This feature makes the usage of AxCrypt much more convenient, and saves you from the trouble of re-entering the passphrase every time.
But, you say, what's then the use of AxCrypt if anyone can walk up to my PC and just double-click?
Under the heading Security, sub-heading Local PC Security you will find a discussion about what is needed to protect your PC locally, and why. The important thing for this discussion is: If anyone can walk up to your PC and it is not protected by a password-protected screen-saver you have no protection anyway! All that is needed for a would-be attacker is access to a PC with for example a diskette or CD-drive, a USB-port or an Internet connection, and it's a few seconds work to install a key-logger or a trojan. Do not trust a PC that has been left unattended and unprotected.
The second reason for the passphrase cache is that if you do not need to enter it every time, you may actually find it reasonable to use a longer and stronger passphrase than otherwise, thus increasing security.
Of course, if you still don't like it, just uncheck the checkbox 'Remember this for decryption'. It's 'sticky', so you'll just have to do it once. You can also manually clear the passphrase cache from either the right-click context menu or the Start-menu.
The basic rule is: If you loose or forget your passphrase or key-file, your documents are lost. There is no back-door into AxCrypt.
The only way to recover a lost passphrase is to try all likely combinations. If you have used a key-file, and lost that, there is nothing to do at all - the number of combinations is simply too large. That is why you must print a paper backup copy if you use key-files.
All that being said, there is a special case where I could possibly help you. If you think you know your passphrase, but not quite, or if it is less than 5 characters long - then I can write and adapt a special program that will try many combinations automatically. This is called a brute force attack.
AxCrypt is specifically engineered to counter brute force attacks, and does it rather well, so this will only work when the number of combinations to try is very small, let's say less than a million.
If you think you may be in a position where you can narrow down the possible combinations enough for me, then there is a slight chance to recover the passphrase.
A brute force attack requires custom programming and many hours, days and possibly weeks and months of computer time, thus I will only do this when compensated and when I feel that that it might be possible. But it's always done on a no cure - no pay basis, this means that if I can't find the passphrase, there's no fee. The fee depends on the amount of programming necessary, typically it'll vary between USD/EUR 50 to 250.
(I've attempted this four times so far, and succeeded once. The password was a word with four letters, where the first letter turned out to be a 'y' instead of 'm' as the user apparently had mistyped. That's the kind of situation where a brute force attack may be successful.)
If your encrypted file is corrupt, you will get a message which in English is "File damaged or manipulated, integrity checksum (HMAC) error." This messages implies that it the file is recognized by AxCrypt, and that you have entered the correct passphrase and/or key-file, and there is hope!
Another message that may be seen is "The file does not appear to be produced by AxCrypt. GUID mismatch." This indicates a severe error in the file to the extent that it is not even recognized as an AxCrypt file. In most cases this is because the file is simply not an AxCrypt encrypted file.
AxCrypt has some features for recovery of damaged files, but there are some limitations. You must also be careful, and start by marking the original (damaged) file as read-only, and then make a copy of it - and always only work on the copy!
There are some limitations and factors to be aware of also.
Your protection against data loss is regular backups. Please backup all your important files - encrypted as well as unencrypted. AxCrypt is not intended to provide any protection against data loss - only against disclosure and undetected manipulation.
Encryption protects your information from prying eyes and undetected modification or corruption. It does not protect against destruction, willfully or by accident.
It bears repetition: Your protection against data loss is regular backups.
Technically it's not really possible to reliably protect your data against destruction with software - except backup software. Of course, software can add safeguards that make it harder to do it by mistake, or even maliciously but in the end you can't protect against vandals that way.
If you are running Windows NT 4, 2000, XP or later you should be using the NTFS file system and let every user of the computer log on as a separate, restricted, user. No-one should normally run as administrator. This will protect your files against deletion by other users of the same computer, but it will not protect against yourself - or any agent acting on your behalf. Please remember that viruses and trojan intrusions will be acting as if on the behalf of the compromised user! (Most worms will even be acting as if being an administrator!)
If your system is compromised by a virus or a trojan, your encrypted data will be protected from theft - but not from destruction.
AxCrypt is not intended to protect against destruction, and there is to my knowledge no such serious software available except for backup software. Any software claiming to provide such protection should be examined carefully to understand exactly what it is it protects against and how. Always backup your data regardless of other measures taken.
There is no such thing as HIPAA compliant encryption or software. Only organizations and procedures can be HIPAA compliant.
The appropriate use of encryption and other Technical Safeguards is governed by the HIPAA Security Standards, 45 CFR 160, 162 and 164. The relevant section is 164.312 Technical Safeguards. No recommendations or requirements concerning specific encryption technologies are made there either, it's specifically pointed out that the regulation is technology-neutral. It's up to each and every organization to evaluate it's position and risks, and then implement required or addressable specifications.
Although the standard in no way refers to it except in comments, the CMS Internet Security Policy, which is the current view of Centers for Medicare & Medicaid Services for their own use, does specify some minimal technology levels for certain cases. AxCrypt meets these requirements for transmission over the Internet - but your organization must independently evaluate if is sufficient to use the same level as the Centers for Medicare & Medicaid Services.
The parts where AxCrypt may (and should) suffice as (part of) a Technical Safeguard are:
The HIPAA Security Standard does allow the use of encryption as the basis for Access Control, that is to say to protect the privacy of data at rest (stored on a hard disk as opposed to traversing the Internet for example). AxCrypt will meet most organizations requirements here too.
Security is a chain only as strong as it's weakest link. In your local system, there are so many other ways to get at your data, that to sacrifice the convenience of a secured passphrase cache just to 'feel' safer, was not thought to be a good idea.
You can always de-select the check-box 'remember this password'.
If you are concerned about physical access to your own computer there are other measures you should take first. For special situations, there is a link installed in the Start-menu called 'Clear and Unload from Memory' that you may invoke manually or programatically.
128-bits is currently enough, and it's not reasonable to provide the full 128-bits anyway using a conventional passphrase. In the future, when AxCrypt supports a hardware token and/or RSA-based key encryption, it will support 256-bits. The really important question is not 128, 256, 448, 2048 or millions of key-bits - it's how they are used. In general, excessive amounts of key-bits is a sign of snake oil. AxCrypt uses proven modes of operation, entropy collection and random number generation as well as work factor increasing key wrapping and individual unique encryption keys for every encryption. See below for details.
The question breaks down to key lengths. The key length used is 128 bits - exhaustive search is not currently believed to be an option, it is computationally infeasible in cryptographic terms.
The problem lies with the passphrases used. This is the weak point.
Using purely random printable characters as your passphrase, you need to specify twenty characters. Tough to remember though ;-)
Using English words, it is more difficult to say, but assuming there are 1 million English words (an optimistic estimate to say the least), that would be equivalent to 20 bits/word. Thus using only English words, you need to specify a sentence with at least 6 words to even approach using the full 128-bit key length. In practice, any normal sentence will consist of words from a much smaller subset of perhaps 10 000 words, equivalent to 13 bits. You then need at least 10 words...
So - the conclusion is: be verbose, be deliberately obtuse, and please mix in something not part of natural language in your passphrases if you want to really use all security the algorithm supplies. And don't use a famous citation, such as the declaration of independence, or anything else likely to be found in a global literature, web or news text archive search.
The cryptological primitives are AES with 128-bit keys for encryption, and SHA-1 for hashes.
The real answer is much more complex, as there are many ways to use and combine these basic primitives.
In the July 2003 issue of PC World magazine, there is a description of how to password protect files using the built-in Windows Compressed Folders of Windows XP and ME. This is a WinZip compatible extension of the Windows Shell (Windows Explorer).
The problem is that since it is WinZip-compatible it suffers from the same weakness as does WinZip. WinZip (and thus Compressed Folders) password protected archives use a proprietary and weak algorithm that is known to have the following weaknesses, exploited in numerous 'Password Recovery' products and services:
AxCrypt also supports numerous additional features such as convenient editing of encrypted files - if a file is stored in a Compress Folder, you must manually extract it, edit, and then drag and drop it back into the archive (you can view it inside the archive without manual extraction, but not modify it).
A very convenient way to get the best of both worlds is to install the full WinZip-utility and then AxCrypt your sensitive zipped archives. WinZip full-version also supports strong encryption of individual files in the archives, but as WinZip is primarily an archiver (the best in my opinion), and AxCrypt is fully focused on encryption (the best in my opinion ;-), you get a nice best-of-breed application when you combine the two.
Normally, AxCrypt files will display the .axx extension or not, depending on your global Windows settings. This behavior may be changed by modifying the Windows registry. AxCrypt does not implement any configuration settings to keep things simple, but if you really want this, two registry files are included in the distribution to make it easier for you.
They are named AxCrypt-HideAxxExtension.reg and AxCrypt-ShowAxxExtension.reg respectively, and are located in the AxCrypt 'etc' directory which usually is "C:\Program Files\Axon Data\AxCrypt\etc".
File2File is a subset of AxCrypt, i.e. AxCrypt does all that File2File does, and more.
| AxCrypt 1.5 or later | File2File | |
| Algorithm | AES | AES |
| Key length | 128 | ? (128 likely) |
| Mode | CBC | CBC |
| Separate Key and Data Encrypting Keys | Yes | No |
| Secure Data Encrypting Key Wrapping | NIST AES Key Wrap | No |
| Open & Re-encrypt | Yes | No |
| Open Source | Yes | No |
| Documented Algorithms | Yes | No |
| Self-decrypting .exe | Yes | Yes |
| File Integrity check | HMAC-SHA1-128 | No |
| Valid Key check | Yes | Yes |
| Command line | Yes | No |
| Secure key cache | Yes | No |
| Installer | Yes | Yes |
| Shell Extension | Yes | Yes |
| Stand alone program | Yes, Decrypt only | No |
| Integrated shredder | One pass PRN overwrite | No |
| Integrated compression | Yes, Zlib | No |
| Multi-file archives | No | No |
| Multi-file and folder selection | Yes | Yes |
If you know of any features or functions that File2File has, but AxCrypt does not, please let me know - I want the comparison table to be as objective as possible.
Passphrases are hashed with SHA-1 to 160 bits, whereof the most significant 128 bits are used as a Key Encrypting Key.
Using a Pseudo Random Number Generator specified in FIPS 186-2 operating on a 160-bit Seed and a 160-bit Key with SHA-1, a 128-bit Master Data Encrypting Key is produced.
Header data and plain text data is encrypted with different derivations of the Master Data Encrypting Key.
The PRNG Seed is a constant accumulating value, dependent on (the presumably secret) user entered keys as well as a 256-byte entropy pool collected continuously through mouse and windows movement, together with further entropy from the system timer and time, as well as a free running bit counter, and the Pentium time stamp counter if available. 128 bytes of the entropy pool are also saved persistently in the registry.
The data in the file consists of many header sections containing information about the file size, file name and file modification times as well as version information, integrity checksum etc. Where appropriate, these are kept encrypted under a separate derived key.
The Key Encrypting Key is wrapped with the NIST AES Key Wrap Algorithm, with increased round count to at least 10 000. The actual count is determined dynamically - faster processor = higher count.
All data concerning the file, namely exact size, original name, file modification and the actual data, is encrypted in Cipher Block Chaining mode with standard padding under different subkey variants of the Master Data Encrypting Key, obtained by encrypting non-secret constants with the Master Data Encrypting Key.
The Initialization Vector for CBC-mode (the same is used for all subkeys) is generated with the same PRNG as above.
Before encryption, the data is compressed using the standard deflate algorithm from RFC 1950 and RFC 1951, if it is determined to be beneficial.
For integrity checking, a RFC 2104 HMAC-SHA1-128, is created for all data (after encryption) except the initial header containing the magic number GUID for file-type id and the HMAC itself. Sometime in the distant future I may write a white-paper describing the algorithms exactly in a more readable form than C++-code - which is what you may look at currently for more details.
Wipe and Delete only overwrites once, with pseudo random data. I'm currently not planning to implement DoD 5220.22 (NISPOM) sanitization, nor Gutmann 35-pass secure-wipe. The cost of retrieving single-overwritten data is prohibitive as it is, if the attacker has the resources for that (as well as getting physical access to the disk) there are many easier and surer ways of getting at the data.
A PC is such an insecure and uncontrolled environment, that to use DoD-style wiping in a running system is severe overkill and misleading. Such wiping should be used prior to destruction or re-use of hard disks, and then only from a stand-alone diskette and CD so that the entire disk surface may be wiped, regardless of operating system structures. I recommend Boot and Nuke for this purpose.
The purpose of AxCrypt wiping is to protect from use of common un-delete tools, not to protect from electron microscopy or special diagnostic hardware and software available to hard disc manufacturers. Wiping 35 times also takes a lot of time...
If a file has the 'hidden' attribute, AxCrypt prior to 1.5 will not see it, and thus not give you the choice of either encrypting or decrypting. Please upgrade!
For versions prior to 1.5.2: Ensure that you are using Visual Studio 6 and have the latest service pack (at least sp5 - if you get error C2440 you need this), also ensure that you have the latest Microsoft Platform SDK (the one that comes with Visual Studio is dated and does not work with AxCrypt - you may receive errors about undefined symbols and also errors in templates used for safe Handle-handling in AxCrypt).
For versions 1.5.2 or later: Ensure that you are using Visual Studio 2002 or later, and have the latest Microsoft Platform SDK installed.
I have not tried compiling under any other compiler - your mileage will vary.